It would be ideal if remote config AND the aws provider both supported an ENV flag for the role, akin to how AWS_PROFILE or AWS_SESSION_TOKEN can be used. This would eliminate the need to edit the provider or remote config when the role changes. Unfortunately AWS does not support an env flag for assume role.

I don't have a lot of familiarity with the code so I did not pursue it very far. But I could see how an env flag for the role could be enabled for remote config by having a section like this for it:

Similarly for the provider the assume_role config could be modified to support an env flag like this

I identified a related issue where the s3 remote does not check for errors after obtaining the AWS credentials. This would lead to crashes
See https://github.com/hashicorp/terraform/pull/10067/files#diff-7bd4c7cfc297dcc74cb94a512b5cece5R71

@stack72 I do not see this as an enhancement, but a critical bug fix in order to support federated IAM accounts with remote state. It’s critical because without it, it’s not possible to use use multiple AWS accounts with federated logins, which is the best practice for securing AWS environments

👍

+1

Really looking forward to this feature/bug fix :-)

+1

@darend after speaking with @jen20 on this - we agree this is good to merge :) There is no straight forward way to test but we can verify this locally

@stack72, one thing I think we should add is an errwrap.Wrapf around the newly returned error so the provenance is more obvious.

@darend after speaking with @jen20 on this - we agree this is good to merge :) There is no straight forward way to test but we can verify this locally

Thanks!

I've been trying this out since it merged - it looks like this works for initial remote state configuration, but the role_arn key doesn't get written as config into the local state file - as such, subsequent runs of terraform commands fail to assume the role before accessing the remote state.

Update: actually the failure case I mentioned above only holds if there's already a remote state in place without the role_arn config key.

@jtopper that's a bug - did you just run remote config again?

I had an existing set of remote state, and ran remote config specifying a role_arn this time. That command completed as expected, but the local copy of the state file didn't have a role arn key in it.

Since I'm hacking on an empty account, I deleted the S3 copy and the local state file, and ran remote config again with a role_arn, after which everything behaves as expected.

I tried to configure remote state from an ec2 which uses the instance profile mechanism. Allways get access denied. Anyone facing the same problem?

I was having an issue, but realized I was still using 0.8.6. After upgrading to 0.8.7, I can confirm it is working.

@bnf2si take a look at your trust profile. By default an EC2 IAM role just has the ec2 service listed as "trusted" in the "trust relationship" tab. To make this works you need to do 2 things:

1. grant your EC2 box the AssumeRole permission for the specific role as in this example:

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": "arn:aws:iam::YOUR_ACCOUNT:role/Admin"
    }
}

But then you need to also add a trust policy to the target role (in this example role/Admin) to the source principal. The easiest way to do this is with a cross account role (but using your own account) in the Trust Relationship:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::YOUR_ACCOUNT:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Hope this helps.

I also found a solution now for my usecase.
I wanted use the same terraform files for access from a) federated account access and b) from an EC2 via profile

With the following assume role configuration in my terraform files I had to attach a policy to "JenkinsAgentCreator" role to allow assuming itself , otherwise I cannot run from terraform from an EC2 via profile.
Proposal: Terraform should recognize that it runs from an EC2 via profile and in this case not assuming the role because it is already assumed somehow.

My example code

provider "aws" {
  region = "${var.aws_region}"
  insecure = "${var.insecure}"
  allowed_account_ids = ["${var.account_id}"] // allow only to do things in sample account, nowhere else

  assume_role {
    role_arn = "arn:aws:iam::${var.account_id}:role/JenkinsAgentCreator"
    session_name = "creating_jenkins_agents"
  }
}

data "terraform_remote_state" "agents" {
    backend = "s3"
    config {
        bucket = "terraform-state-eclipseprojects.etas-dev.com"
        key = "agents_golden_ami/terraform.tfstate"
        region = "eu-central-1"
        encrypt = "true"
        role_arn = "arn:aws:iam::${var.account_id}:role/JenkinsAgentCreator"
    }
} 

Problem: Running Terraform from an EC2 instance with an instance profile that allows assuming roles, Terraform can assume another role in the AWS provider block, however, cannot assume another role for remote config using S3 backend with the "role_arn" configuration variable.

Workaround: Script that performs an STS assume role (assumes that assumed role has the appropriate s3 privileges), script disables remote config, script reenables remote config with the STS temporary credentials.

Note: Terraform will complain when the credentials expire.

"Error reloading remote state: ExpiredToken: The provided token has expired."

Rerun the script. Run Terraform.

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.